src/libs/tryAGI.OpenAI/openapi.yaml (3)

17744-17755: Future-proof connector_id or document update cadence

Hard-coding an enum of connector IDs is fine for strong validation, but it will break clients when new connectors ship. Either:

• Document that this enum will evolve and may require frequent client updates, or
• Switch to a relaxed validation (e.g., pattern: '^connector_[a-z0-9]+$') and move the known set to docs.

Example diff for the relaxed approach:

-        connector_id:
-          enum:
-            - connector_dropbox
-            - connector_gmail
-            - connector_googlecalendar
-            - connector_googledrive
-            - connector_microsoftteams
-            - connector_outlookcalendar
-            - connector_outlookemail
-            - connector_sharepoint
-          type: string
+        connector_id:
+          type: string
+          pattern: '^connector_[a-z0-9]+$'

---

17765-17773: Approval object semantics: precedence and completeness checks

Good move to reuse MCPToolFilter via $ref for always/never. Two follow-ups:

• Define precedence if a tool matches both always and never (e.g., never overrides always).
• Ensure the alternate string enum path includes both 'always' and 'never' (the snippet shows only 'always').

Proposed doc tweak:

               description: "Specify which of the MCP server's tools require approval. Can be
-`always`, `never`, or a filter object associated with tools
+`always`, `never`, or an object with `always`/`never` filters. If a tool matches both,
+`never` takes precedence. This setting determines which tools require user approval
 that require approval.\n"

Please confirm that the accompanying string variant enum includes both:

• always
• never

---

17834-17848: MCPToolFilter: add constraints and clarify AND/OR semantics

The schema looks good. Two refinements:

• Enforce uniqueness and non-empty tool_names.
• Clarify whether multiple fields are combined with AND (recommended) or OR when both are provided.

Apply:

       MCPToolFilter:
         title: MCP tool filter
         type: object
         properties:
           read_only:
             type: boolean
             description: "Indicates whether or not a tool modifies data or is read-only. If an
 MCP server is [annotated with `readOnlyHint`](https://modelcontextprotocol.io/specification/2025-06-18/schema#toolannotations-readonlyhint),
 it will match this filter.\n"
           tool_names:
             title: MCP allowed tools
             type: array
             items:
               type: string
-            description: List of allowed tool names.
+            description: List of allowed tool names.
+            minItems: 1
+            uniqueItems: true
         additionalProperties: false
-        description: "A filter object to specify which tools are allowed.\n"
+        description: "A filter object to specify which tools are allowed. When multiple fields are provided, they are combined with logical AND."

Defining this as a reusable schema is a solid improvement in consistency.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

src/libs/tryAGI.OpenAI/openapi.yaml (2)

17735-17741: No invalid union here: anyOf already wraps the array and the filter object

The snippet around lines 17735–17741 shows you’re using an anyOf composition on allowed_tools, which is valid OpenAPI 3.x syntax and will be accepted by standard validators. The original comment—which assumed a bare array followed by a dangling $ref—doesn’t match the current code.

• The union is correctly modelled under anyOf:

allowed_tools:
  anyOf:
    - title: MCP allowed tools
      type: array
      items:
        type: string
      description: A string array of allowed tool names
    - $ref: '#/components/schemas/MCPToolFilter'
  description: "List of allowed tool names or a filter object.\n"
  nullable: true

• If you need exclusive “either array or object” semantics, you may opt to replace anyOf with oneOf. Otherwise, no change is needed.

Please disregard the original suggestion to “add a oneOf around array vs. MCPToolFilter,” since the schema is already valid as written.

Likely an incorrect or invalid review comment.

---

17786-17792: Indentation Verified: oneOf aligns with schema‐level keys
The parent schema’s keys (type, properties, description) are indented 6 spaces. The proposed oneOf: block also uses 6 spaces, so it will be placed correctly at the schema level.
No linter errors are expected when applying the patch as-is.